Forward error correction (FEC) can be mandatory, optional or unsupported depending on the Ethernet application, physical medium, host and software. A mismatch can prevent link establishment or produce an unstable link with heavy errors. Diagnose it from the exact interfaces and standards context instead of toggling settings until the port comes up.

Identify the full link mode

Record both endpoint devices, cards or adapters, ports, software, configured speed, breakout mode, lane count, optical or copper application and installed media. Note whether an intermediate retimer, gearbox or media converter exists.

“100G QSFP28” is not a complete link definition. Different physical-medium-dependent (PMD) applications can have different signaling and FEC requirements. Two modules can fit the same cage while expecting different host behavior.

Preserve the original symptoms

Capture interface state, module inventory, configured FEC, operational FEC, lane status and all available corrected and uncorrected error counters. Save exact alarms and timestamps before clearing counters or changing configuration.

Classify the symptom:

• No link or no block/frame lock.
• Link up only when one setting is forced.
• Link flaps after initial establishment.
• Corrected errors rise continuously.
• Uncorrected errors or packet errors appear.
• One lane behaves differently from the others.

Determine the required FEC

Use the host and module documentation for the exact PMD and software release. Common names such as RS-FEC, BASE-R FEC, FC-FEC or “auto” are not interchangeable across every platform.

Confirm whether each endpoint can disable, force or negotiate FEC and whether “auto” selects the same operational mode at both ends. Some interfaces require a particular FEC for compliance or margin. Disabling it merely to achieve link-up can produce an unsupported or unreliable service.

The 100G QSFP28 selection guide explains how PMD, lane arrangement and FEC belong in the selection decision.

Compare both endpoints explicitly

Create a simple record with configured and operational values for endpoint A and endpoint B. Include speed, breakout, lane mapping and autonegotiation because these settings can affect FEC behavior.

If one endpoint reports FEC and the other does not, verify whether the command is unsupported, the optic hides the state or the port is not in the intended mode. Do not infer a match from missing output.

For mixed-vendor links, use documentation from both vendors. The same label in two interfaces may not imply the same defaults or negotiation behavior.

Separate FEC mismatch from a marginal signal

A correct FEC configuration does not repair dirty connectors, excessive loss, receiver overload, marginal electrical signal integrity or an unsupported cable. Conversely, corrected errors do not automatically prove a FEC mismatch; FEC is designed to correct errors within its capability.

Compare optical power, lane data, cable length, connector condition, temperature and error trends. If corrected errors increase rapidly, determine whether the raw channel is marginal. If uncorrected errors occur, the correction capability is being exceeded or the mode is wrong.

Test one controlled change at a time

After confirming the documented requirement, make a planned change at both endpoints where necessary. Record the before-and-after configuration and counters. Allow enough observation time and traffic to evaluate stability.

Do not leave a port in an undocumented state merely because it passed a short ping test. Verify operational FEC, traffic, errors, alarms and rollback.

Build an escalation package

Include:

• Endpoint hardware and software.
• Exact media and module identities.
• PMD, speed, breakout and lane mapping.
• Configured and operational FEC at both ends.
• Interface, lane and error outputs before and after tests.
• Optical power, cable type/length and recent changes.

This package allows the host or optics supplier to reproduce the intended mode instead of discussing a generic “100G link.”

Frequently asked questions

Can a FEC mismatch keep the link completely down?

Yes. The result depends on the application and platform; it can prevent synchronization, cause flapping or create severe errors.

Is “FEC auto” safe on both endpoints?

Only if the exact platforms and application select compatible modes. Verify the operational value rather than relying on the configured label.

Should FEC be disabled when the link works without it?

Not without confirming that the PMD and platform support that operation and that the service meets the required error performance.

Are corrected FEC errors always a fault?

No. FEC is intended to correct errors. Use rate, trend, margin, alarms and uncorrected errors to judge the condition.

Can good optical power rule out a FEC problem?

No. Power does not prove that endpoint modes, lanes, modulation and FEC agree.

What changes after a breakout configuration?

Lane mapping, port identities, supported speeds and FEC behavior can change. Verify the exact host documentation and both endpoint configurations.

Qualify the complete port mode before ordering

Share the endpoint platforms, software, port speed, breakout, PMD, FEC, fiber or cable type, reach and quantity. Axonode can help organize the exact media requirement and coordinate compatible coding and validation without claiming that form factor alone proves interoperability.

Contact Axonode for a high-speed link review. For broader DCI planning, read the high-speed data-center interconnect guide.